Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rewrite Min/Max to handle all cases correctly. Fixes 545 spectest failures. #863

Merged
merged 3 commits into from
Oct 9, 2019
Merged

Rewrite Min/Max to handle all cases correctly. Fixes 545 spectest failures. #863

merged 3 commits into from
Oct 9, 2019

Conversation

nlewycky
Copy link
Contributor

@nlewycky nlewycky commented Oct 4, 2019 •
edited by syrusakbary
Loading

Description

The llvm backend was not quite following the Wasm spec for {F32,F64,F32x4xF64x2}{Min,Max}. We used the @llvm.minnum and @llvm.maxnum intrinsics which don't handle the corner cases the same. When we tried to use @llvm.minimum and @llvm.maximum which do, we get an internal error from the x86 backend. I was hoping that crash would go away with the upgrade to LLVM 9, but it does not.

Reimplement these operations using plain LLVM instructions.

Review

  • Add a short description of the the change to the CHANGELOG.md file

syrusakbary
syrusakbary reviewed Oct 4, 2019
View reviewed changes
lib/llvm-backend/src/code.rs
.build_call(intrinsics.minimum_f32, &[v1, v2], &state.var_name())
.try_as_basic_value()
.left()
.unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add comments in each of this implementations adding context, such as:

LLVM minmax doesn't work on the versions I tried (8, 9) because ...
So we are writing our own implementation of minmax each time we call `f32min` ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@syrusakbary
Copy link
Member

Apart from the comment added. Rather than adding the IR for minmax each time that we call min on a value, can we just create 4 different functions (in the LLVM IR) and call them?
That way LLVM will decide if it wants to inline them or not (and perhaps the code will become a bit simpler (specially once LLVM fixes certain things).

@nlewycky
Copy link
Contributor Author

nlewycky commented Oct 4, 2019

Apart from the comment added. Rather than adding the IR for minmax each time that we call min on a value, can we just create 4 different functions (in the LLVM IR) and call them?
That way LLVM will decide if it wants to inline them or not (and perhaps the code will become a bit simpler (specially once LLVM fixes certain things).

I don't think we should do that? The first reason is that when we call builder.create_some_instruction, it doesn't necessarily create an instruction! If the llvm Value is known, say because it's a constant because the webassembly code happened to have (f32.const 0.0) then the builder will simply return another constant if it can. The code looks like it handles the fully generic case, but it will get specialized down as we write it out.

Secondly, we're in the middle of emitting a function. LLVM is fine with seeing more functions at any time, but LLVMModuleCodeGenerator is not. It expects next_function() to produce a single function which it will then produce machine code for in finalize(). We can fix this of course, but it's not a change that will be confined to the implementation of Operator::F32Min and friends.

@nlewycky
Copy link
Contributor Author

nlewycky commented Oct 9, 2019

bors r+

bors bot added a commit that referenced this pull request Oct 9, 2019
@bors @nlewycky
Merge #863
2695093 
863: Rewrite Min/Max to handle all cases correctly. Fixes 545 spectest failures. r=nlewycky a=nlewycky

# Description
The llvm backend was not quite following the Wasm spec for {F32,F64,F32x4xF64x2}{Min,Max}. We used the `@llvm.minnum` and `@llvm.maxnum` intrinsics which don't handle the corner cases the same. When we tried to use `@llvm.minimum` and `@llvm.maximum` which do, we get an internal error from the x86 backend. I was hoping that crash would go away with the upgrade to LLVM 9, but it does not.

Reimplement these operations using plain LLVM instructions.

# Review

- [x] Add a short description of the the change to the CHANGELOG.md file


Co-authored-by: Nick Lewycky <[email protected]>
@bors
Copy link
Contributor

bors bot commented Oct 9, 2019

Build succeeded

  • wasmerio.wasmer

@bors bors bot merged commit 749691c into master Oct 9, 2019
@bors bors bot deleted the feature/llvm-min-max branch October 9, 2019 23:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@syrusakbary syrusakbary syrusakbary approved these changes

@losfair losfair Awaiting requested review from losfair

@MarkMcCaskey MarkMcCaskey Awaiting requested review from MarkMcCaskey

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@nlewycky @syrusakbary